While the functioning of the basic model for our interlocking trees datastore, which does not require indexing or tables to construct or use it has been described in our prior patent applications, there are valuable additional structures and processes that can be added to it. We often refer to our interlocking trees datastore as KStore (or sometimes just K, although we also refer to it as a KStore structure in some discussions). The previous patent applications describing KStore already on file in the U.S. are identifiable by Ser. Nos. 10/385,421, 10/666,382, and 10/759,466, all of which we incorporate by this reference in their respective entireties. We have found that in order to make the KStore structure more marketable and easier to use, several innovations have become important. We describe these in order to facilitate the interoperation of the structure with applications software and with users, and in general to make it easier to use. In doing so, the KStore, or KStores, become integrated into a system that is facile at handling data for nearly any desired use.
Being able to get data into and knowledge out of the KStore structure using common software interfaces will make the structure more viable as a commodity and more useful to the public, because it will enable them to access it with the tools they already have or are used to. With the demonstration of the components needed to facilitate the use of the KStore structure to the data within the structure, it will become apparent to one of ordinary skill how to apply those components to nearly any kind of application for its interaction with a KStore.
Up until now, the KStore was accessed by its engine with custom-built software. Being entirely novel, it was useful to those with the ability to build such software. Therefore, for any application, access needed to be redesigned and again, apparent to one of ordinary skill how to apply those components to nearly any kind of application for its interaction with a KStore.
Up until now, the KStore was accessed by its engine with custom-built software. Being entirely novel, it was useful to those with the ability to build such software. Therefore, for any application, access needed to be redesigned and again, custom built. A way to avoid custom builds for those processes of the K Engine that were constantly reused needed to be found to make KStore more commercially viable. If it could be found, all this custom building and rebuilding could be avoided for many, if not nearly all applications that either needed to build a KStore and provide query access to it. Likewise this could facilitate use of a KStore for those applications that simply needed to get query answers from it. We chose to provide a set of intermediary software entities and simple method steps to accomplish this. These intermediary processes or objects need to address the issues associated with variations and complexity of applications which need access to a KStore, including multiple and disparate input data sources, and types and formats of queries.
For example, if a data source uses ORACLE database structures and is directly attached to the KStore in any manner with only a direct intermediary constructed to handle the connection, or if the data comes in through a transactional RDBMS system across the Internet and is cloaked in HTML or XML, or if the data comes from a real time sensor array, or whatever format the data takes, the underlying structure of the KStore should not have to change to accommodate such input forms.
Accordingly, we feel that an intermediary that gains common usage and allows many to take advantage of the inherent value of KStores for any purpose would be essential to making KStore commercially viable.
Therefore, we created the processes to enable one of ordinary skill in the programming arts, access to a KStore, without having to understand the KStore applications Engine or the KStore structure. We generated a system by which such a programmer could build and/or access a KStore for any purpose.
Additionally we needed to allow for switching states between queries simply accessing the KStore, and queries that allow learning and therefore add to a KStore's structure. Numerous other innovations for putting intelligence into the interface between a KStore and its users are also described and claimed herein.